diff --git a/content/nim/support/_index.md b/content/nim/support/_index.md new file mode 100644 index 000000000..c6f9aa4c7 --- /dev/null +++ b/content/nim/support/_index.md @@ -0,0 +1,6 @@ +--- +title: "Support" +description: "How to get Support for F5 NGINX Management Suite" +weight: 999 +url: /nginx-instance-manager/support/ +--- \ No newline at end of file diff --git a/content/nim/support/contact-support.md b/content/nim/support/contact-support.md new file mode 100644 index 000000000..708ba7e70 --- /dev/null +++ b/content/nim/support/contact-support.md @@ -0,0 +1,103 @@ +--- +docs: DOCS-817 +doctypes: +- concept +tags: +- docs +title: Where to go for support +toc: true +weight: 300 +--- + +## Support policy + +F5 NGINX Instance Manager follows the support policy detailed in the knowledge base article: [K000140156](https://my.f5.com/manage/s/article/K000140156). + +{{}} +Support licenses for NGINX Instance Manager **do not include** support for the NGINX instances being managed. + +Community support is available for NGINX Open Source instances on the [NGINX mailing list](http://mailman.nginx.org/mailman/listinfo). If you need support for NGINX Plus or [prebuilt NGINX Open Source packages](https://nginx.org/en/linux_packages.html), you must [purchase an NGINX license](https://www.nginx.com/purchase-nginx/). +{{}} + +--- + +## Contact NGINX support + +For help with installing, troubleshooting, or using the NGINX Instance Manager, contact support through the [MyF5 Customer Portal](https://account.f5.com/myf5). + +--- + +## Support script + +The Support team might ask you to run one or both of the following scripts to troubleshoot issues. Attach the script outputs to your support case. + +- `/usr/share/nginx-manager` – for troubleshooting issues with the NGINX Instance Manager host. +- `/usr/share/nginx-agent` – for troubleshooting issues with a data plane instance running the NGINX Agent. + +### Run the support script on the NGINX Instance Manager host + +1. Open an SSH connection to the NGINX Instance Manager host and log in. +2. Run the following command: + + ```bash + /usr/share/nginx-manager/support.sh + ``` + +### Run the script on a data plane instance + +1. Open an SSH connection to the data plane instance and log in. +2. Run the following command: + + ```bash + /usr/share/nginx-agent/support.sh + ``` + +### Collected information + +The scripts collect the following information: + +- System details (`/etc/os-release`). +- Checks for installed NGINX, NGINX Instance Manager, and NGINX Agent instances. +- NGINX data: + - `nginx -T` (current configuration). + - `nginx -V` (version and runtime details). + - `/var/log/nginx/*` (log files). +- NGINX Instance Manager log files: + - `/var/log/nginx-manager/*` +- API queries from NGINX Instance Manager: + - `GET /api/v0/instances` + - `GET /api/v0/scan` + - `GET /api/v0/about/system` + - `GET /api/v0/about/license` +- NGINX Agent log files: + - `/var/log/nginx-agent/*` + +### Output file + +The script creates a file in the `/tmp` directory, such as `/tmp/nginx-manager-log.tar.gz`. Review the file and **remove confidential information** before sharing it with F5. + +For example, if your `/etc/nginx-manager` directory contains private keys or certificates, remove them using: + +```bash +gzip -d /tmp/nginx-manager-log.tar.gz + +tar -f /tmp/nginx-manager-log.tar.gz \ + --delete /etc/nginx-manager/example.key \ + --delete /etc/nginx-manager/example.crt + +gzip -9 /tmp/nginx-manager-log.tar.gz +``` + +{{}}Files shared with F5 are protected under the [F5 Support and Maintenance Privacy Statement](https://www.f5.com/company/policies/support-and-maintenance-privacy-statement).{{}} + +--- + +## Additional resources + +### AskF5 knowledge base + +Find solutions to common issues and corner cases on [AskF5](https://support.f5.com/csp/knowledge-center/software/NGINX?module=NGINX%20Instance%20Manager). + +### NGINX training and professional services + +Get expert guidance and hands-on support from [NGINX Professional Services](https://www.nginx.com/services/#package_detail_section). diff --git a/content/nim/support/k8s-support-package.md b/content/nim/support/k8s-support-package.md new file mode 100644 index 000000000..b4bcd7a09 --- /dev/null +++ b/content/nim/support/k8s-support-package.md @@ -0,0 +1,150 @@ +--- +docs: DOCS-1123 +doctypes: +- reference +- task +tags: +- docs +title: Create a support package from a Helm installation +toc: true +weight: 200 +--- + +{{< include "/nim/decoupling/note-legacy-nms-references.md" >}} + +## Overview + +Use the Kubernetes support package script to collect system and service information for troubleshooting and debugging. The script packages the data into a tar archive that you can share with [NGINX Customer Support]({{< relref "nim/support/contact-support.md" >}}). + +--- + +## Before you begin + +To follow this guide, ensure you have: + +- `bash` 4.0 or higher. + +--- + +## Usage + +The F5 NGINX Instance Manager Helm chart includes the `k8s-support-package.sh` script located at: + +- `/support-package/k8s-support-package.sh`. + +### Steps to create a support package + +1. Download the latest NGINX Instance Manager Helm chart: + + ```bash + helm repo add nginx-stable https://helm.nginx.com/stable + helm repo update + helm pull nginx-stable/nms + tar zxvf nms-.tgz + ``` + +2. Run the Kubernetes support package script. For available options, refer to the [arguments](#arguments) section: + + ```bash + bash ./nms/charts/nms-hybrid/support-package/k8s-support-package.sh + ``` + + The support package is saved in the directory where the script is run. + +3. Extract the package using the `tar` command: + + ```bash + tar -xvf k8s-support-pkg-.tar.gz + ``` + +--- + +## Arguments + +The table below lists arguments available for the Kubernetes support package script. + +| Short | Long | Description | Example | Default | +|-------|------------------------|------------------------------------------------------------|---------------|----------| +| `-h` | `--help` | Prints information about the script arguments to `stdout`. | `--help` | N/A | +| `-o` | `--output_dir` | Specifies the output directory for the tar archive. | `-o ~/output` | `$(pwd)` | +| `-n` | `--namespace` | Specifies the namespace of the Helm installation. | `-n nms` | `` | +| `-xd` | `--exclude_databases` | Excludes Dqlite database backup data. | `-xd` | `False` | +| `-xt` | `--exclude_timeseries` | Excludes ClickHouse time series data. | `-xt` | `False` | +| `-m` | `--modules` | Includes specific modules in Dqlite database backup data. | `-m acm` | `False` | + +--- + +## Package contents + +The Kubernetes support package includes directories with detailed information about your cluster, namespace, application, and database state. + +### k8s-support-package.log + +A log of all output generated by the `k8s-support-package.sh` script. + +### chart-files + +A snapshot of the Helm chart files in the parent directory, excluding the directory where the script runs. + +### version-info + +Versions of: + +- Helm chart +- `kubectl` tool +- `helm` tool +- NGINX gateway +- ClickHouse + +### cluster-info + +Cluster-related data, including: + +- Cluster details +- Node information +- Storage class configurations + +### namespace-info + +Namespace-specific details, including: + +- General namespace data +- Events +- API version +- API services and resources + +### app-info + +Application-related information for NGINX Instance Manager: + +- Deployments +- Services +- Persistent Volumes and Claims +- Secrets and Configmaps +- Pods + +### pod-logs + +Logs of processes for NGINX Instance Manager, NGINX gateway, and ClickHouse. Files in this directory follow the naming convention: `pod_name-.logs`. + +### pod-system-info + +Status and state details for each pod, including: + +- Operating system version +- Environment variables +- Running processes + +### dqlite + +The script uses the `dqlite-backup` executable (located in `/etc/nms/scripts/` within relevant containers) to collect database dumps. Data is saved in: + +- `dqlite/core` +- `dqlite/dpm` +- `dqlite/integrations` + +If the `--modules` flag is specified, data is saved to `dqlite/`. + +### timeseries + +Contains metrics, events, and statistics from the `nms` ClickHouse database. \ No newline at end of file diff --git a/content/nim/support/support-package.md b/content/nim/support/support-package.md new file mode 100644 index 000000000..0d82d34fe --- /dev/null +++ b/content/nim/support/support-package.md @@ -0,0 +1,140 @@ +--- +docs: DOCS-818 +doctypes: +- reference +- task +tags: +- docs +title: Create a support package +toc: true +weight: 200 +--- + +{{< include "/nim/decoupling/note-legacy-nms-references.md" >}} + +## Overview + +The support package script can be used to collect information about your system for troubleshooting and debugging issues. + +The script collects system and service information and then packages the data into a tar archive, which you can share with [NGINX Customer Support]({{< relref "/nms/support/contact-support.md" >}}). + +## Usage + +The F5 NGINX Instance Manager installer copies the `support-package.sh` script to the following location: `/etc/nms/scripts/support-package.sh`. + +{{< note >}} +The supported shell is `bash`. +{{< /note >}} + +To create a support package: + +1. Run the support package script. The script requires root privileges to run. + + ``` bash + sudo bash /etc/nms/scripts/support-package.sh + ``` + + The support package is saved in the same location from where the script was run (if no `-t` argument is passed). + + (Optional) If you use a different Instance Manager config file than the default `/etc/nms/nms.conf` file, run the support package script with the `-c` flag and specify the path to your config file: + + ```bash + sudo bash /etc/nms/scripts/support-package.sh -c /your/config.conf + ``` + +2. To extract the package, use the `tar` command: + + ```bash + tar -xvf support-pkg-.tar.gz + ``` + +### Arguments + +The following table lists the arguments you can use with the support package script. + +{{}} + +| Short | Long | Description | Example | Default | +| ----- | ---------------------- | ------------------------------------------------------------------- | ---------------------- | ------------------- | +| `-h` | `--help` | Prints information about the script arguments to stdout. | `--help` | N/A | +| `-o` | `--output_dir` | The output directory where the tar archive is saved. | `-o ~/output` | `$(pwd)` | +| `-n` | `--nginx_log_path` | The directory where the NGINX log files are located. | `-n /var/log/nginx` | `/var/log/nginx` | +| `-c` | `--nms_config_path` | The path to the Instance Manager config file. | `-c /etc/nms/nms.conf` | `/etc/nms/nms.conf` | +| `-m` | `--manager_log_path` | The directory where the Instance Manager log file is located. | `-m /var/log/nms` | `/var/log/nms` | +| `-t` | `--target_host` | The Instance Manager address (host:port). | `-t 127.0.0.1:443` | `127.0.0.1:443` | +| `-xd` | `--exclude_databases` | Excludes database data from the support package. | `--exclude_databases` | N/A | +| `-xt`| `--exclude_timeseries` | Excludes timeseries data from the support package. | `--exclude_timeseries` | N/A | + +{{}} + +## Package Contents + +The support package includes several directories containing information about the system, service, and database state. + +The information included is based on the NGINX products installed and configured. + +### nginx-logs + +The access and error logs of the instances that Instance Manager monitors. + +The access logs display the HTTP traffic for Instance Manager that's routed by the NGINX instance. The error log contains NGINX errors that occurred during runtime. + +### nms-logs + +The logs of the Instance Manager processes. + +You can pipe the logs to `grep` to view entries belonging to only one of the three `nms` processes. For example, to view `nms-core` logs, run the following command: + +```bash +cat nms.log | grep 'COR' +``` + +The following table shows the `nms` processes and pattern to `grep` on: + +{{}} + +| Process name | Pattern | +| ------------- | ------- | +| nms-core | 'COR' | +| nms-dpm | 'DPM' | +| nms-ingestion | 'ING' | + +{{}} + +### service-information + +Information about the Instance Manager and NGINX services running on the host. For each `nms` process and the `nginx` instance, the script collects: + +- `journalctl` (10000 most recent rows) +- `systemctl status` + +### system-information + +The status and state information of the host running Instance Manager, including the following: + +- System metrics (memory usage, CPU usage, etc.) +- File permissions of the Instance Manager +- Firewall or SELinux state +- Network interfaces +- Network information (hostname, iptables) +- Environment variables +- Disk usage of select directories +- Operating system version +- Installed Instance Manager version +- Instance Manager license + +### dqlite snapshot + +The support package script uses the `-c` flag ( or `--nms_config_path`) to get the Instance Manager configuration. If the configuration file is not specified, the script uses the default value `/etc/nms/nms.conf`. + +{{< note >}} +If the Instance Manager configuration file does not specify addresses for the `core` and `dpm` databases, the default values are assumed: `127.0.0.1:7891` and `127.0.0.1:7890`. +{{< /note >}} + +The support package script uses a small Go executable file called `dqlite-backup` (located in `/etc/nms/scripts/`) to connect to the databases and generate data dumps. + +The collected data is saved to the directories `dqlite/core`, `dqlite/dpm`. + +### timeseries + +This folder contains status information, dumps, and statistics for the `nms` ClickHouse database. In particular, for metrics and events. diff --git a/content/nim/system-configuration/configure-clickhouse.md b/content/nim/system-configuration/configure-clickhouse.md index e7ed7e33c..57756549f 100644 --- a/content/nim/system-configuration/configure-clickhouse.md +++ b/content/nim/system-configuration/configure-clickhouse.md @@ -10,44 +10,48 @@ toc: true weight: 100 --- +{{< include "/nim/decoupling/note-legacy-nms-references.md" >}} + ## Overview -Follow the steps in this guide to update the `/etc/nms/nms.conf` file if you used a custom address, username, or password or enabled TLS when installing ClickHouse. F5 NGINX Management Suite requires this information to connect to ClickHouse. +Follow this guide to update the `/etc/nms/nms.conf` file if you used a custom address, username, or password, or enabled TLS during ClickHouse installation. NGINX Instance Manager requires this information to connect to ClickHouse. -## Default ClickHouse Values {#default-values} +## Default ClickHouse values {#default-values} -Unless specified differently in the `/etc/nms/nms.conf` file, NGINX Management Suite uses the following values for ClickHouse by default: +Unless otherwise specified in the `/etc/nms/nms.conf` file, NGINX Instance Manager uses the following default values for ClickHouse: {{< include "installation/clickhouse-defaults.md" >}} --- -## Use Custom Address, Username, Password +## Use custom address, username, or password -If your ClickHouse installation has a different address, username, or password than the default values, you need to configure NGINX Management Suite to connect to ClickHouse. +If your ClickHouse installation uses a custom address, username, or password, update the NGINX Instance Manager configuration to match. -To set custom values for the ClickHouse address, username, and password: +To set custom values: -1. On the NGINX Management Suite server, open the `/etc/nms/nms.conf` file for editing. -2. Change the following settings to match your ClickHouse configuration: +1. Open the `/etc/nms/nms.conf` file on the NGINX Instance Manager server. +2. Update the following settings to match your ClickHouse configuration: - ``` yaml + ```yaml clickhouse: address: tcp://localhost:9000 username: password: ``` -3. Save the changes and close the file. +3. Save and close the file. --- ## Configure TLS -If you configured ClickHouse to work with TLS, take the following steps to update the settings in the NGINX Management Suite `nms.conf` file: +If you enabled TLS for ClickHouse, update the `nms.conf` file settings to enable secure connections. + +To configure TLS: -1. On the NGINX Management Suite server, open the `/etc/nms/nms.conf` file for editing. -2. Configure the `clickhouse` TSL settings to suit your environment: +1. Open the `/etc/nms/nms.conf` file on the NGINX Instance Manager server. +2. Update the `clickhouse` TLS settings as needed: ```yaml clickhouse: @@ -90,4 +94,4 @@ If you configured ClickHouse to work with TLS, take the following steps to updat migrations_path: /test/migrations ``` -3. Save the changes and close the file. +3. Save and close the file. diff --git a/content/nim/system-configuration/configure-gateway.md b/content/nim/system-configuration/configure-gateway.md index ae8c98f58..9fb2497a1 100644 --- a/content/nim/system-configuration/configure-gateway.md +++ b/content/nim/system-configuration/configure-gateway.md @@ -1,59 +1,102 @@ --- -description: Follow the steps in this guide to fine-tune the NGINX proxy gateway for - F5 NGINX Management Suite to support large data planes running numerous NGINX Agents. docs: DOCS-1131 doctypes: - tutorial tags: - docs -title: Optimize NGINX Proxy Gateway for Large Data Planes +title: Optimize NGINX proxy gateway for large data planes toc: true weight: 400 --- +{{< include "/nim/decoupling/note-legacy-nms-references.md" >}} + ## Overview -If the NGINX proxy gateway for F5 NGINX Management Suite alerts you that there are not enough worker connections, you may need to modify the NGINX configuration (`/etc/nginx/nginx.conf` on the NGINX Management Suite host) to allow more worker connections and increase the number of file descriptors for worker processes. +If the NGINX proxy gateway for F5 NGINX Instance Manager alerts you that there are not enough worker connections, you may need to update the NGINX configuration (`/etc/nginx/nginx.conf`) on the NGINX Instance Manager host. These updates include increasing the number of worker connections and file descriptors for worker processes to support larger data planes effectively. + +--- + +## Configure worker connections + +By default, the NGINX Instance Manager's NGINX configuration allows 1,024 worker connections (`worker_connections`). However, this default may not be sufficient for large data planes with numerous NGINX Agents. + +We recommend allowing **twice as many worker connections as the number of NGINX Agents** you need to support. Each NGINX Agent requires two persistent gRPC connections to the NGINX Instance Manager host. For example, if you have 1,000 NGINX Agents, configure approximately 2,000 worker connections. + +To align with the worker connection count, you should also adjust the maximum number of file descriptors (`worker_rlimit_nofile`) that worker processes can open. Since `rlimit_nofile` is a system setting, ensure your Linux user limits allow the required number of file descriptors. + +### Update worker connections and file descriptors + +1. Open the NGINX configuration file on the NGINX Instance Manager host: + + ```bash + sudo nano /etc/nginx/nginx.conf + ``` + +2. Modify the `worker_connections` and `worker_rlimit_nofile` settings as needed: + + ```nginx + events { + worker_connections 2000; + } + + worker_rlimit_nofile 2000; + ``` + +3. Save the changes and restart NGINX: + + ```bash + sudo systemctl restart nginx + ``` + +For more information, refer to the official NGINX documentation: +- [worker_connections](http://nginx.org/en/docs/ngx_core_module.html#worker_connections) +- [worker_rlimit_nofile](http://nginx.org/en/docs/ngx_core_module.html#worker_rlimit_nofile) + +--- -## Configure Worker Connections +## Configure gRPC for agents -By default, the NGINX Management Suite's NGINX configuration (`/etc/nginx/nginx.conf`) allows 1024 worker connections (`worker_connections`). However, this default may be insufficient if you have a large data plane with numerous NGINX Agents. To ensure optimal performance, we suggest allowing **twice as many worker connections as the number of NGINX Agents** you want to support. This is because each NGINX Agent requires two persistent gRPC connections to the NGINX Management Suite. If you have 1,000 NGINX Agents, for example, you should allow around 2,000 worker connections. +By default, the NGINX Instance Manager's NGINX configuration (`/etc/nginx/conf.d/nms-http.conf`) times out gRPC connections from NGINX Agents after 10 minutes using the `client_body_timeout` directive. You can adjust this timeout to better suit your needs. For example, a shorter timeout quickly clears connections from agents that disconnect unexpectedly without completing the gRPC protocol teardown. -You may also want to adjust the maximum number of file descriptors (`worker_rlimit_nofile`) that a process can open to align with the number of worker connections. Note that `rlimit_nofile` is a system setting, so make sure to check the user limits for your Linux distribution, as these may be more restrictive. +### Update gRPC timeout settings -To update the number of worker connections and file descriptors, edit the NGINX configuration file (`/etc/nginx/nginx.conf`) on the NGINX Management Suite host. For more information on the NGINX worker connection and file descriptor settings, refer to the following NGINX Core topics: +1. Open the gRPC configuration file on the NGINX Instance Manager host: -- [NGINX worker_connections](http://nginx.org/en/docs/ngx_core_module.html#worker_connections) -- [NGINX worker_rlimit_nofile](http://nginx.org/en/docs/ngx_core_module.html#worker_rlimit_nofile) + ```bash + sudo nano /etc/nginx/conf.d/nms-http.conf + ``` -## Configure GRPC for Agents +2. Locate the gRPC service locations and modify the `client_body_timeout` value as needed. For example: -By default, the NGINX Management Suite's NGINX configuration (`/etc/nginx/conf.d/nms-http.conf`) times out the gRPC connection from Agents at 10 minutes using the client body timeout (`client_body_timeout`). You can adjust this value to suit your needs; a lower value will time out gRPC connection from aborted Agent connections faster. An aborted Agent connection can happen when the Agent disconnects unexpectedly from the network without going through the gRPC protocol teardown process. + ```nginx + # gRPC service for metric ingestion + location /f5.nginx.agent.sdk.MetricsService { + # uncomment to enable mTLS with agent + # auth_request /check-agent-client-cert; + include /etc/nms/nginx/errors-grpc.loc_conf; + grpc_socket_keepalive on; + grpc_read_timeout 5m; + grpc_send_timeout 5m; + client_body_timeout 10m; + grpc_pass grpc://ingestion-grpc-service; + } -To update the timeout value, edit the NGINX Management Suite's NGINX configuration file (`/etc/nginx/conf.d/nms-http.conf`) on the NGINX Management Suite host. For example: + # gRPC service for DPM + location /f5.nginx.agent.sdk.Commander { + # uncomment to enable mTLS with agent + # auth_request /check-agent-client-cert; + include /etc/nms/nginx/errors-grpc.loc_conf; + grpc_socket_keepalive on; + grpc_read_timeout 5m; + grpc_send_timeout 5m; + client_body_timeout 10m; + grpc_pass grpc://dpm-grpc-service; + } + ``` -```nginx - # gRPC service for metric ingestion - location /f5.nginx.agent.sdk.MetricsService { - # uncomment to enable mTLS with agent - # auth_request /check-agent-client-cert; - include /etc/nms/nginx/errors-grpc.loc_conf; - grpc_socket_keepalive on; - grpc_read_timeout 5m; - grpc_send_timeout 5m; - client_body_timeout 10m; - grpc_pass grpc://ingestion-grpc-service; - } +3. Save the changes and restart NGINX: - # gRPC service for DPM - location /f5.nginx.agent.sdk.Commander { - # uncomment to enable mTLS with agent - # auth_request /check-agent-client-cert; - include /etc/nms/nginx/errors-grpc.loc_conf; - grpc_socket_keepalive on; - grpc_read_timeout 5m; - grpc_send_timeout 5m; - client_body_timeout 10m; - grpc_pass grpc://dpm-grpc-service; - } -``` + ```bash + sudo systemctl restart nginx + ``` diff --git a/content/nim/system-configuration/configure-selinux.md b/content/nim/system-configuration/configure-selinux.md index 5881762e4..812642d7e 100644 --- a/content/nim/system-configuration/configure-selinux.md +++ b/content/nim/system-configuration/configure-selinux.md @@ -1,6 +1,4 @@ --- -description: Learn how to load the provided F5 NGINX Management Suite SELinux policy - to secure your NGINX Management Suite deployment. docs: DOCS-796 doctypes: - task @@ -11,120 +9,107 @@ toc: true weight: 250 --- -{{< shortversions "2.0.0" "latest" "nimvers" >}} +{{< include "/nim/decoupling/note-legacy-nms-references.md" >}} ## Overview -You can use the optional SELinux policy module included in the package to secure F5 NGINX Management Suite operations with flexible, mandatory access control that follows the principle of least privilege. +You can use the optional SELinux policy module included in the package to secure F5 NGINX Instance Manager operations with flexible, mandatory access control that follows the principle of least privilege. -The scope of the SELinux policy allows NGINX Management Suite to perform all operations needed to support the default configuration. This includes inter-process communication on the default Unix sockets and TCP as an alternative. Other changes may require manual adjustments to the default policy for the application to work. +The scope of the SELinux policy allows NGINX Instance Manager to perform all operations needed to support the default configuration. This includes inter-process communication on the default Unix sockets and TCP as an alternative. Other changes may require manual adjustments to the default policy for the application to work. -{{< important >}}The attached SELinux policy module is optional. As such, the module is not loaded automatically during installation even on SELinux-enabled systems. You must manually load the policy module as detailed in the following steps.{{< /important >}} +{{< important >}}The SELinux policy module is optional. It is not loaded automatically during installation, even on SELinux-enabled systems. You must manually load the policy module using the steps below.{{< /important >}} --- -## Before You Begin +## Before you begin -To complete this tutorial, take the following preparatory steps: +Take these preparatory steps before configuring SELinux: 1. Enable SELinux on your system. -2. Install the following tools: `load_policy`, `semodule`, and `restorecon`. -3. [Install NGINX Management Suite]({{< relref "/nim/deploy/_index.md" >}}) with SELinux module files in place. +2. Install the tools `load_policy`, `semodule`, and `restorecon`. +3. [Install NGINX Instance Manager]({{< relref "/nim/deploy/_index.md" >}}) with SELinux module files in place. -{{< important >}}SELinux can be configured to use `permissive` mode. In `permissive` mode, policy violations are logged instead of enforced. Make sure you know which mode your SELinux configuration uses.{{< /important >}} +{{< important >}}SELinux can use `permissive` mode, where policy violations are logged instead of enforced. Verify which mode your configuration uses.{{< /important >}} --- -## Install NGINX Management Suite Policy {#selinux-install} +## Install NGINX Instance Manager policy {#selinux-install} -The NGINX Management Suite installer places the SELinux policy files in the following locations: +The NGINX Instance Manager installer places SELinux policy files in these locations: - `/usr/share/selinux/packages/nms.pp` - loadable binary policy module - `/usr/share/selinux/devel/include/contrib/nms.if` - interface definitions file - `/usr/share/man/man8/nms_selinux.8.gz` - policy man page -You can interact with these files to learn about the policy. See the following section for steps on how to load the policy. +You can load and configure the SELinux policy using the following steps. -### Load Policy and Set Default Labels {#selinux-server} +### Load policy and set default labels {#selinux-server} -To use the SELinux policy that's included with NGINX Management Suite, take the following steps: +To load the SELinux policy included with NGINX Instance Manager: -1. Load the NGINX Management Suite policy: +1. Load the NGINX Instance Manager policy: ```bash sudo semodule -n -i /usr/share/selinux/packages/nms.pp sudo /usr/sbin/load_policy ``` -1. Run the following commands to restore the default SELinux labels for the files and directories related to NGINX Management suite: - - ```bash - sudo restorecon -F -R /usr/bin/nms-core - sudo restorecon -F -R /usr/bin/nms-dpm - sudo restorecon -F -R /usr/bin/nms-ingestion - sudo restorecon -F -R /usr/bin/nms-integrations - sudo restorecon -F -R /usr/lib/systemd/system/nms.service - sudo restorecon -F -R /usr/lib/systemd/system/nms-core.service - sudo restorecon -F -R /usr/lib/systemd/system/nms-dpm.service - sudo restorecon -F -R /usr/lib/systemd/system/nms-ingestion.service - sudo restorecon -F -R /usr/lib/systemd/system/nms-integrations.service - sudo restorecon -F -R /var/lib/nms/modules/manager.json - sudo restorecon -F -R /var/lib/nms/modules.json - sudo restorecon -F -R /var/lib/nms/streaming - sudo restorecon -F -R /var/lib/nms - sudo restorecon -F -R /var/lib/nms/dqlite - sudo restorecon -F -R /var/run/nms - sudo restorecon -F -R /var/lib/nms/modules - sudo restorecon -F -R /var/log/nms - ``` - -1. Restart the NGINX Management Suite services: +2. Restore default SELinux labels for related files and directories: ```bash - sudo systemctl restart nms + sudo restorecon -F -R /usr/bin/nms-core + sudo restorecon -F -R /usr/bin/nms-dpm + sudo restorecon -F -R /usr/bin/nms-ingestion + sudo restorecon -F -R /usr/bin/nms-integrations + sudo restorecon -F -R /usr/lib/systemd/system/nms.service + sudo restorecon -F -R /usr/lib/systemd/system/nms-core.service + sudo restorecon -F -R /usr/lib/systemd/system/nms-dpm.service + sudo restorecon -F -R /usr/lib/systemd/system/nms-ingestion.service + sudo restorecon -F -R /usr/lib/systemd/system/nms-integrations.service + sudo restorecon -F -R /var/lib/nms/modules/manager.json + sudo restorecon -F -R /var/lib/nms/modules.json + sudo restorecon -F -R /var/lib/nms/streaming + sudo restorecon -F -R /var/lib/nms + sudo restorecon -F -R /var/lib/nms/dqlite + sudo restorecon -F -R /var/run/nms + sudo restorecon -F -R /var/lib/nms/modules + sudo restorecon -F -R /var/log/nms ``` -### Add Ports to SELinux Context {#selinux-ports-add} - -NGINX Management Suite uses the `nms_t` context in the policy module. The following example shows how to add a new port to the context. You should add external ports to the firewall exception list. Note, as a system admin, you're responsible for any custom configurations that differ from the default policy. +3. Restart NGINX Instance Manager services: -To add TCP ports `10000` and `11000` to the `nmx_t` context, run the following commands: + ```bash + sudo systemctl restart nms + ``` -```bash -sudo semanage port -a -t nms_port_t -p tcp 10000 -sudo semanage port -a -t nms_port_t -p tcp 11000 -``` +### Add ports to SELinux context {#selinux-ports-add} -If you've already defined the port context, use `-m`: +NGINX Instance Manager uses the `nms_t` context in the policy module. To add new TCP ports to this context: -```bash -sudo semanage port -m -t nms_port_t -p tcp 10000 -sudo semanage port -m -t nms_port_t -p tcp 11000 -``` +1. Add TCP ports `10000` and `11000` to the `nms_port_t` context: -Verify the port has the correct label by running the the following `seinfo --portcon` commands: + ```bash + sudo semanage port -a -t nms_port_t -p tcp 10000 + sudo semanage port -a -t nms_port_t -p tcp 11000 + ``` -``` bash -$ seinfo --portcon=10000 +2. If the port context is already defined, use `-m` to modify it: -Portcon: 4 - portcon sctp 1024-65535 system_u:object_r:unreserved_port_t:s0 - portcon tcp 10000 system_u:object_r:nms_port_t:s0 - portcon tcp 1024-32767 system_u:object_r:unreserved_port_t:s0 - portcon udp 1024-32767 system_u:object_r:unreserved_port_t:s0 + ```bash + sudo semanage port -m -t nms_port_t -p tcp 10000 + sudo semanage port -m -t nms_port_t -p tcp 11000 + ``` -$ seinfo --portcon=11000 +3. Verify the port has the correct label: -Portcon: 4 - portcon sctp 1024-65535 system_u:object_r:unreserved_port_t:s0 - portcon tcp 1024-32767 system_u:object_r:unreserved_port_t:s0 - portcon tcp 11000 system_u:object_r:nms_port_t:s0 - portcon udp 1024-32767 system_u:object_r:unreserved_port_t:s0 -``` + ```bash + seinfo --portcon=10000 + seinfo --portcon=11000 + ``` -### Remove Ports from SELinux Context {#selinux-ports-remove} +### Remove ports from SELinux context {#selinux-ports-remove} -If you uninstall NGINX Management Suite, you should remove the ports. To do this, run the following commands: +If you uninstall NGINX Instance Manager, remove the associated ports: ```bash sudo semanage port -d -t nms_t 10000 @@ -133,29 +118,29 @@ sudo semanage port -d -t nms_t 11000 --- -## Enabling SELinux for NGINX Agent {#selinux-agent} +## Enable SELinux for NGINX Agent {#selinux-agent} -The following SELinux files are added when installing the NGINX Agent package: +The following SELinux files are added when you install the NGINX Agent package: - `/usr/share/selinux/packages/nginx_agent.pp` - loadable binary policy module - `/usr/share/selinux/devel/include/contrib/nginx_agent.if` - interface definitions file - `/usr/share/man/man8/nginx_agent_selinux.8.gz` - policy man page -To load the NGINX Agent policy, run the following commands: +To load the NGINX Agent policy, run: {{< include "installation/agent-selinux.md" >}} -### Add Ports to NGINX Agent SELinux Context +### Add ports to NGINX Agent SELinux context -You can configure the NGINX Agent to work with SELinux. Make sure you add external ports to the firewall exception list. +Make sure to add external ports to the firewall exception list. -The following example shows how to allow external ports outside the HTTPD context. You may need to enable NGINX to connect to these ports. +To allow external ports outside the HTTPD context, run: ```bash sudo setsebool -P httpd_can_network_connect 1 ``` -{{}}For additional information on using NGINX with SELinux, refer to the guide [Using NGINX and NGINX Plus with SELinux](https://www.nginx.com/blog/using-nginx-plus-with-selinux/).{{}} +{{}}For more information, see [Using NGINX and NGINX Plus with SELinux](https://www.nginx.com/blog/using-nginx-plus-with-selinux/).{{}} --- diff --git a/content/nim/system-configuration/configure-telemetry.md b/content/nim/system-configuration/configure-telemetry.md index e39b50d8f..93376cbc5 100644 --- a/content/nim/system-configuration/configure-telemetry.md +++ b/content/nim/system-configuration/configure-telemetry.md @@ -4,28 +4,30 @@ doctypes: - task tags: - docs -title: Configure Telemetry and Web Analytics +title: Configure telemetry and web analytics toc: true weight: 260 --- ## Overview -The F5 NGINX Management Suite platform lets you share telemetry and web analytics data with F5 NGINX. This data provides valuable insights into software usage and adoption, which NGINX uses to improve product development and support customers worldwide. This document provides an overview of the transmitted data, instructions for enabling or disabling the features, and instructions for configuring firewalls. +F5 NGINX Instance Manager lets you share telemetry and web analytics data with F5. This data provides insights into software usage, helping improve product development and customer support. This document explains the data that’s sent, how to enable or disable telemetry, and how to configure firewall settings. ## Telemetry -NGINX Management Suite sends a limited set of telemetry data to NGINX for analysis. This data is associated only with the subscription ID from the applied license and does not include any personally identifiable information or specific details about the management plane, data plane, or other details. +NGINX Instance Manager sends limited telemetry data linked to the subscription ID in your license. The data doesn’t include personal details or specifics about the management or data planes. -The purpose of collecting this telemetry data is to: +### Why telemetry is collected -- Drive and validate product development decisions to ensure optimal outcomes for users. -- Assist the Customer Success and Support teams in helping users achieve their goals. -- Fulfill Flexible Consumption Program reporting requirements by automatically reporting product usage to F5 NGINX, saving users time. +Telemetry helps: -By sharing this telemetry data, we can improve NGINX Management Suite and provide better support to users. +- Guide product development to improve user outcomes. +- Support Customer Success and Support teams in resolving issues. +- Automatically report usage for Flexible Consumption Program requirements, saving you time. -### Captured Telemetry Data Points +By sharing telemetry, you help improve NGINX Instance Manager and its support. + +### Telemetry data points The table below shows the captured telemetry data points, the trigger conditions, and their respective purposes. Additional data points may be added in the future. @@ -33,48 +35,49 @@ The table below shows the captured telemetry data points, the trigger conditions |
Data Point
| Triggering Event | Purpose | |--------------------------|------------------------------------|-------| -| Installation | The first time NGINX Management Suite processes are started. | To measure the time it takes to install and start using NGINX Management Suite. | -| Login | When a user logs in to NGINX Management Suite. No data about the user is sent, only the fact that a user successfully authenticated and the timestamp of the login event. | To understand how often users or systems access NGINX Management Suite. | -| Start/Stop processes | When any NGINX Management Suite processes are started or stopped. | To gauge how often users upgrade NGINX Management Suite or troubleshoot issues. This information helps F5 Support diagnose issues. | -| Adding Data Plane(s) | When NGINX Agent registers with NGINX Management Suite for the first time. No data about the data plane is sent, just that an NGINX Agent registered with the platform. | To understand the frequency and quantity of data planes being added to NGINX Management Suite. This information helps inform our scale and performance targets and helps F5 Support diagnose issues. | +| Installation | The first time NGINX Instance Manager processes are started. | To measure the time it takes to install and start using NGINX Instance Manager. | +| Login | When a user logs in to NGINX Instance Manager. No data about the user is sent, only the fact that a user successfully authenticated and the timestamp of the login event. | To understand how often users or systems access NGINX Instance Manager. | +| Start/Stop processes | When any NGINX Instance Manager processes are started or stopped. | To gauge how often users upgrade NGINX Instance Manager or troubleshoot issues. This information helps F5 Support diagnose issues. | +| Adding Data Plane(s) | When NGINX Agent registers with NGINX Instance Manager for the first time. No data about the data plane is sent, just that an NGINX Agent registered with the platform. | To understand the frequency and quantity of data planes being added to NGINX Instance Manager. This information helps inform our scale and performance targets and helps F5 Support diagnose issues. | | Product Usage | Data is sent daily or when Send Usage is selected from the Licenses page in the web interface or initiated using the API. (Requires a [JWT license]({{< relref "/nim/admin-guide/license/add-license.md#jwt-license" >}}).) | To track and report commercial usage in accordance with entitlement and Flexible Consumption Program (FCP) requirements. | {{}} -### Enabling and Disabling Telemetry - -Once you [apply a valid license to NGINX Management Suite]({{< relref "/nim/admin-guide/license/add-license.md" >}}), the platform will automatically try to send the specified telemetry data points to F5 NGINX. It may also include data points captured shortly before the license was applied. For example, if you install NGINX Management Suite and immediately apply the license, the *Installation* data point will be sent. +### Enable or disable telemetry -#### Disable Telemetry +Once you [apply a valid license]({{< relref "/nim/admin-guide/license/add-license.md" >}}), telemetry data starts transmitting. If the license is applied immediately after installation, the *Installation* data point is also sent. -You can disable telemetry sharing at any time by going to the NGINX Management Suite web interface and selecting **Settings > License**. You can also disable the feature using the `/license` API endpoint. You can re-enable telemetry from the same locations if you change your mind. +#### Disable telemetry -### Firewall Settings for Telemetry +You can disable telemetry anytime by: -To support telemetry for the NGINX Management Suite, allow outbound TCP connections in your firewall to 159.60.126.0/25 on port 443. +- Going to **Settings > License** in the web interface. +- Using the [`/license` API endpoint]({{< relref "/nim/fundamentals/api-overview.md" >}}). -If you are using a JWT license, make sure to allow inbound and outbound access on port 443 to the following URLs: +Re-enable telemetry in the same way. -- [https://product.apis.f5.com](https://product.apis.f5.com) -- [https://product-s.apis.f5.com/ee](https://product-s.apis.f5.com/ee) +### Firewall settings for telemetry ---- +To enable telemetry, configure your firewall to allow: -## Web Analytics +- Outbound TCP connections to `159.60.126.0/25` on port `443`. +- For JWT licenses, inbound and outbound access to: + - `https://product.apis.f5.com` + - `https://product-s.apis.f5.com/ee` -Web analytics are collected when users interact with the platform through their web browsers. This data is sent directly from the users' browsers to NGINX and is used to understand user interaction patterns and improve the user experience. +## Web analytics -### Enabling and Disabling Web Analytics +Web analytics track interactions with NGINX Instance Manager through users’ web browsers. The data is sent directly to NGINX and helps improve user experience. -#### Opt Out of Web Analytics During Provisioning +### Opt out of web analytics during provisioning -During provisioning or upgrade, administrators will see a notice about web analytics collection with an option to opt out. This notice includes a link to F5’s official [Privacy Notice](https://www.f5.com/company/policies/privacy-notice). Administrators can opt out by selecting the provided link. +During provisioning or upgrades, administrators see a notice about web analytics collection with an option to opt out. The notice includes a link to the [Privacy Notice](https://www.f5.com/company/policies/privacy-notice). -#### Disable Web Analytics +### Disable web analytics -If administrators miss the initial opt-out message, they can follow these steps:: +If administrators miss the initial opt-out: -1. Select the **User** icon in the top-right corner of the screen. -2. Select **"Collect interaction data (all users)"** to turn the setting off. +1. Select the **User** icon in the top-right corner. +2. Select **"Collect interaction data (all users)"** to clear the setting. -{{}}The admin user’s decision to opt in or out of web analytics affects all users on the platform.{{}} +{{}}The admin's decision to enable or disable web analytics applies to all users.{{}} diff --git a/content/nim/system-configuration/configure-vault.md b/content/nim/system-configuration/configure-vault.md index 4d41c0283..2474884f8 100644 --- a/content/nim/system-configuration/configure-vault.md +++ b/content/nim/system-configuration/configure-vault.md @@ -1,40 +1,38 @@ --- -description: Follow the steps in this guide to configure F5 NGINX Management Suite to - use HashiCorp's Vault for storing secrets. docs: DOCS-999 doctypes: - tutorial tags: - docs -title: Configure Vault for Storing Secrets +title: Configure Vault for storing secrets toc: true weight: 200 --- -{{< shortversions "2.6.0" "latest" "nimvers" >}} +{{< include "/nim/decoupling/note-legacy-nms-references.md" >}} -HashiCorp's Vault is a popular solution for storing secrets. While F5 NGINX Management Suite provides encryption-at-rest for secrets stored on disk, if you have an existing Vault installation, you may prefer to store all secrets in one place. NGINX Management Suite provides a driver you can use to connect to existing Vault installations and store secrets. +HashiCorp's Vault is a popular solution for storing secrets. While F5 NGINX Instance Manager provides encryption-at-rest for secrets stored on disk, you may prefer to store all secrets in one place if you have an existing Vault installation. NGINX Instance Manager provides a driver to connect to existing Vault installations and store secrets. -## Before You Begin +## Before you begin -To complete the steps in this guide, you need the following: +To complete the steps in this guide, you need: -- A working understanding of [Vault](https://www.vaultproject.io) and its operations -- A running version of [Vault 1.8.8 or later](https://www.vaultproject.io/docs/install) +- A working understanding of [Vault](https://www.vaultproject.io) and its operations. +- A running version of [Vault 1.8.8 or later](https://www.vaultproject.io/docs/install). --- -## Create Periodic Service Tokens {#create-periodic-service-tokens} +## Create periodic service tokens {#create-periodic-service-tokens} -Access to a vault requires a renewable token. +Access to a Vault requires a renewable token. -{{}}If you attempt to use the vault's Root Token, NGINX Management Suite will not be able to start the secrets driver, as that token is not renewable.{{}} +{{}}If you attempt to use the Vault's Root Token, NGINX Instance Manager won't start the secrets driver, as that token is not renewable.{{}} -To create a periodic service token for NGINX Management Suite, take the following steps: +To create a periodic service token for NGINX Instance Manager: 1. Use the Vault user interface to create a new policy. - The "default" policy has no access to store or retrieve secrets, and the root policy is too broad. We recommend creating a policy called `nms_secrets` with these capabilities: + The "default" policy doesn't allow storing or retrieving secrets, and the root policy is too broad. Create a policy called `nms_secrets` with these capabilities: ```text path "secret/*" { @@ -42,9 +40,7 @@ To create a periodic service token for NGINX Management Suite, take the followin } ``` -2. Create an initial service token that will last so long as it's renewed on time until it's manually revoked. We recommend a period of 24 hours, which is used in the following example. NGINX Management Suite will always attempt to renew tokens before expiring, so shorter times also work. - - To create a token, take the following step, substituting your vault's Root Token for `$VAULT_ROOT_TOKEN` and your vault's address for `$VAULT_ADDR`: +2. Create a renewable service token. We recommend a period of 24 hours. NGINX Instance Manager renews tokens automatically, so shorter periods also work. Run the following, replacing `$VAULT_ROOT_TOKEN` with your Vault's Root Token and `$VAULT_ADDR` with your Vault's address: ```bash curl -X POST --header "X-Vault-Token: $VAULT_ROOT_TOKEN" \ @@ -52,14 +48,14 @@ To create a periodic service token for NGINX Management Suite, take the followin $VAULT_ADDR/v1/auth/token/create | jq -r ".auth.client_token" > periodic_token.txt ``` -3. Verify your token works: +3. Verify the token works: ```bash curl --header "X-Vault-Token: $(cat periodic_token.txt)" \ $VAULT_ADDR/v1/auth/token/lookup-self | jq .data ``` -4. If everything looks good, stop the `nms-core` service and configure NGINX Management Suite to use your token: +4. If everything works, stop the `nms-core` service and configure NGINX Instance Manager to use the token: ```bash sudo systemctl stop nms-core @@ -69,13 +65,12 @@ To create a periodic service token for NGINX Management Suite, take the followin --- -## Start Using Vault to Store Secrets {#start-using-vault} - -1. To use the new token on the NGINX Management Suite server, open the `/etc/nms/nms.conf` file for editing. +## Start using Vault to store secrets {#start-using-vault} -2. Update the `secrets` section indented under `core` to tell NGINX Management Suite how to handle secrets. +1. Open the `/etc/nms/nms.conf` file on the NGINX Instance Manager server. +2. Update the `secrets` section under `core` to specify how to manage secrets. - For example, an internal development installation of Vault might use: + For example, an internal Vault installation might use: ```text secrets: @@ -96,7 +91,7 @@ To create a periodic service token for NGINX Management Suite, take the followin ``` 3. Save the changes and close the file. -4. Restart the NGINX Management Suite services to start using Vault to store secrets: +4. Restart the NGINX Instance Manager services to start using Vault: ```bash sudo systemctl restart nms @@ -104,29 +99,31 @@ To create a periodic service token for NGINX Management Suite, take the followin --- -## Switching between Vault and Local Encryption {#switch-to-from-vault} - -After you've set up Vault to store your secrets, you can easily switch between local encryption and Vault as desired. +## Switch between Vault and local encryption {#switch-to-from-vault} -### Switch to Local Encryption +After setting up Vault, you can switch between local encryption and Vault. -To switch from using Vault to local disk encryption, take the following steps: +### Switch to local encryption -1. Stop NGINX Management Suite to ensure exclusive access to the secrets: +1. Stop NGINX Instance Manager: ```bash sudo systemctl stop nms ``` -2. Run the following command to migrate secrets from Vault to your local disk: +2. Migrate secrets to local storage: ```bash sudo nms-core secret migrate-secrets-to-local ``` -3. Update the `core/secrets/driver` line from `/etc/nms/nms.conf`, which you added in the previous section, to say `driver: local`. +3. Update the `core/secrets/driver` in `/etc/nms/nms.conf` to use the local driver: + + ```text + driver: local + ``` -4. Restart NGINX Management Suite: +4. Restart NGINX Instance Manager: ```bash sudo systemctl start nms @@ -134,23 +131,27 @@ To switch from using Vault to local disk encryption, take the following steps: ### Switch to Vault -To switch from using local encryption back to Vault, take the following steps: +To switch from using local encryption back to Vault: -1. Stop NGINX Management Suite to ensure exclusive access to the secrets: +1. Stop NGINX Instance Manager: ```bash sudo systemctl stop nms ``` -2. Run the following command to migrate secrets from your local disk to Vault: +2. Migrate secrets to Vault: ```bash sudo nms-core secret migrate-secrets-to-vault ``` -3. Update the `core/secrets/driver` line from `/etc/nms/nms.conf`, which you added in the previous section, to say `driver: vault`. +3. Update the `core/secrets/driver` line in `/etc/nms/nms.conf` to use the Vault driver: -4. Restart NGINX Management Suite: + ```text + driver: vault + ``` + +4. Restart NGINX Instance Manager: ```bash sudo systemctl start nms @@ -160,21 +161,10 @@ To switch from using local encryption back to Vault, take the following steps: ## Troubleshooting -
-Token has expired - -If the vault service token is manually revoked or expires before renewal -- possibly because NGINX Management Suite was shut down and was -unavailable to renew the token, all access to stored secrets will fail. - -To resolve this problem, you need is to supply a new service token using `nms-core secret vault-token`. See the [Create Periodic Service Tokens](#create-periodic-service-tokens) section above for details on generating and supplying a new token. -
- -
+### Token has expired -
-Certs are missing after switching to/from Vault +If the Vault service token is revoked or expires, access to stored secrets will fail. To resolve this, generate and supply a new service token using `nms-core secret vault-token`. See [create periodic service tokens](#create-periodic-service-tokens) for details. -When configuring Vault for storing secrets, NGINX Management Suite assumes that no secrets have been stored previously and won't migrate any existing stored secrets. All existing certs must be uploaded again. +### Missing certs after switching -Stored secrets are not deleted: secrets remain in the encrypted disk storage or vault. We can't guarantee that the secrets will remain accessible forever. If you want to recover the missing secrets, you can [switch back to the other method for storing secrets](#switch-to-from-vault) following the instructions above. Then restart NGINX Management Suite to see the old secrets again. -
+When switching to Vault, NGINX Instance Manager doesn't migrate existing secrets. Reupload missing certs or switch back to the original storage method to recover access. Restart the service to view the restored secrets. diff --git a/content/nim/system-configuration/configure-with-config.md b/content/nim/system-configuration/configure-with-config.md index 0ae81bf6a..b21afff18 100644 --- a/content/nim/system-configuration/configure-with-config.md +++ b/content/nim/system-configuration/configure-with-config.md @@ -5,30 +5,30 @@ doctypes: - task tags: - docs -title: Configure NGINX Management Suite with nms.conf +title: Configure NGINX Instance Manager with nms.conf toc: true weight: 1 --- +{{< include "/nim/decoupling/note-legacy-nms-references.md" >}} ## Overview -This guide explains how to configure F5 NGINX Management Suite by editing the **/etc/nms/nms.conf** file. +This guide explains how to configure F5 NGINX Instance Manager by editing the **/etc/nms/nms.conf** file. -## Before You Start +## Before you start -Before you set up NGINX Management Suite, ensure: +Before you set up NGINX Instance Manager, ensure: -- You have access to the **/etc/nms/nms.conf** file on the host where NGINX Management Suite is installed. +- You have access to the **/etc/nms/nms.conf** file on the host where NGINX Instance Manager is installed. - You understand the required settings and options. - You have the necessary permissions to edit the configuration file. -## Configuration Details +## Configuration details -Edit the **/etc/nms/nms.conf** file to configure NGINX Management Suite. The comments in the example configuration file provide details on each setting and its usage. +Edit the **/etc/nms/nms.conf** file to configure NGINX Instance Manager. The comments in the example configuration file provide details on each setting and its usage. -
- Example nms.conf with default settings and values +### Example nms.conf with default settings and values ```yaml # This is the default /etc/nms/nms.conf file distributed with Linux packages. @@ -192,4 +192,3 @@ clickhouse: # skip_verify: true # key_path ``` -
\ No newline at end of file