nautobot 2.0.4__py3-none-any.whl → 2.1.0b1__py3-none-any.whl

nautobot/docs/user-guide/administration/installation/nautobot.md

@@ -1,367 +0,0 @@
-# Installing Nautobot
-
-This section of the documentation discusses installing and configuring the Nautobot application itself.
-
-These instructions will guide you through the following actions:
-
-* Establish a Nautobot root directory for the application environment
-* Create a `nautobot` system account
-* Create a Python virtual environment (virtualenv)
-* Install Nautobot and all required Python packages
-* Run the database schema migrations
-* Aggregate static resource files on disk
-* Verify the installation using the development/test server
-
-!!! important
-    Your database server and Redis must have been successfully installed before continuing with deployment steps. If you haven't done that yet, please visit the guide on [Installing Nautobot Dependencies](index.md#installing-nautobot-dependencies)
-
-## Choose your `NAUTOBOT_ROOT`
-
-You need to select a directory path where everything related to Nautobot will be installed. We will use this value across the documentation and it will be referred to as `NAUTOBOT_ROOT`.
-
-We will be using this path as the home directory of the `nautobot` user.
-
-!!! tip
-    We have selected `/opt/nautobot`, but you may use any directory you choose.
-
-Later on, we will need to set this directory path as the `NAUTOBOT_ROOT` environment variable to tell Nautobot where to find its files and settings.
-
-## Create the Nautobot System User
-
-Create a system user account named `nautobot`. This user will own all of the Nautobot files, and the Nautobot web services will be configured to run under this account.
-
-The following command also creates the `/opt/nautobot` directory and sets it as the home directory for the user.
-
-```no-highlight
-sudo useradd --system --shell /bin/bash --create-home --home-dir /opt/nautobot nautobot
-```
-
-## Setup the Virtual Environment
-
-A Python [virtual environment](https://docs.python.org/3/tutorial/venv.html) or *virtualenv* is like a container for a set of Python packages. A virtualenv allows you to build environments suited to specific projects without interfering with system packages or other projects.
-
-When installed per the documentation, Nautobot uses a virtual environment in production.
-
-In the following steps, we will have you create the virtualenv within the `NAUTOBOT_ROOT` you chose in the previous step. This is the same we had you set as the home directory as the `nautobot` user.
-
-!!! note
-    Instead of deliberately requiring you to activate/deactivate the virtualenv, we are emphasizing on relying on the `$PATH` to access programs installed within it. We find this to be much more intuitive and natural when working with Nautobot in this way.
-
-### Create the Virtual Environment
-
-As root, we're going to create the virtualenv in our `NAUTOBOT_ROOT` as the `nautobot` user to populate the `/opt/nautobot` directory with a self-contained Python environment including a `bin` directory for scripts and a `lib` directory for Python libraries.
-
-=== "Ubuntu/Debian"
-
-    ```no-highlight
-    sudo -u nautobot python3 -m venv /opt/nautobot
-    ```
-
-=== "CentOS/RHEL8"
-
-    ```no-highlight
-    sudo -u nautobot python3.8 -m venv /opt/nautobot
-    ```
-
-### Update the Nautobot `.bashrc`
-
-So what about the `NAUTOBOT_ROOT`? We've referenced this environment variable several times. Here is where it finally gets set.
-
-We need to set the `NAUTOBOT_ROOT` environment variable for the `nautobot` user and make sure that it always set without having to do it manually.
-
-Run this command to update `~/.bashrc` for `nautobot` so that anytime you become `nautobot`, your `NAUTOBOT_ROOT` will be set automatically.
-
-```no-highlight
-echo "export NAUTOBOT_ROOT=/opt/nautobot" | sudo tee -a ~nautobot/.bashrc
-```
-
-## Sudo to nautobot
-
-It is critical to install Nautobot as the `nautobot` user so that we don't have to worry about fixing permissions later.
-
-```no-highlight
-sudo -iu nautobot
-```
-
-Observe also that you can now echo the value of the `NAUTOBOT_ROOT` environment variable that is automatically set because we added to `.bashrc`:
-
-```no-highlight
-echo $NAUTOBOT_ROOT
-```
-
-Example output:
-
-```no-highlight
-/opt/nautobot
-```
-
-!!! warning
-    Unless explicitly stated, all remaining steps requiring the use of `pip3` or `nautobot-server` in this document should be performed as the `nautobot` user!
-
-## Understanding the Virtual Environment
-
-Because the `nautobot` user was created with `NAUTOBOT_ROOT` set as its home directory and we had you set the shell to `/bin/bash`, the binary path `$NAUTOBOT_ROOT/bin` is automatically added to the beginning of the `$PATH` environment variable:
-
-=== "Ubuntu 20.04"
-
-    ```no-highlight
-    echo $PATH
-    ```
-
-    Example output:
-
-    ```no-highlight
-    /opt/nautobot/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
-    ```
-
-=== "RHEL8 flavors"
-
-    ```no-highlight
-    echo $PATH
-    ```
-
-    Example output:
-
-    ```no-highlight
-    /opt/nautobot/.local/bin:/opt/nautobot/bin:/opt/nautobot/.local/bin:/opt/nautobot/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
-    ```
-
-Therefore, any commands executed by the `nautobot` user will always check `$NAUTOBOT_ROOT/bin` first.
-
-Since `NAUTOBOT_ROOT` also contains the Python virtualenv for Nautobot, all of the commands you will execute as the `nautobot` user, will automatically prefer the virtualenv's commands because they come first in the `$PATH`.
-
-As the `nautobot` user, you may use `which pip3` to confirm that you are using the correct version of `pip3`. The path should match that of `$NAUTOBOT_ROOT/bin`. For example:
-
-```no-highlight
-which pip3
-```
-
-Example output:
-
-```no-highlight
-/opt/nautobot/bin/pip3
-```
-
-This makes sure that the version of Python you're using, as well any dependencies that you install, remain isolated in this environment.
-
-## Prepare the Virtual Environment
-
-Before we install anything into the virtualenv, we want to make sure that Pip is running the latest version.
-
-[Pip](https://pip.pypa.io/) is Python's package installer and is referred interchangeably as `pip` or `pip3`. For the purpose of this document, we'll deliberately be referring to it as `pip3`. Many common issues can be solved by running the latest version of Pip. Before continuing with installing Nautobot, upgrade Pip to its latest release.
-
-We also want to deliberately install the `wheel` library which will tell Pip to always try to install wheel packages if they are available. A [wheel is a pre-compiled Python package](https://realpython.com/python-wheels/), which is quicker and safer to install because it does not require development libraries or `gcc` to be installed on your system just so that some more advanced Python libraries can be compiled.
-
-```no-highlight
-pip3 install --upgrade pip wheel
-```
-
-## Install Nautobot
-
-=== "PostgreSQL (Ubuntu and RHEL Flavors)"
-
-    Use Pip to install Nautobot:
-
-    ```no-highlight
-    pip3 install nautobot
-    ```
-
-=== "MySQL (Ubuntu and RHEL Flavors)"
-
-    Use Pip to install Nautobot with the MySQL client:
-
-    ```no-highlight
-    pip3 install "nautobot[mysql]"
-    ```
-
-Great! We have `NAUTOBOT_ROOT` ready for use by the `nautobot` user, so let's proceed to verifying the installation.
-
-## Verify your Nautobot Installation
-
-You should now have a fancy `nautobot-server` command in your environment. This will be your gateway to all things Nautobot! Run it to confirm the installed version of `nautobot`:
-
-```no-highlight
-nautobot-server --version
-```
-
-## Configuration
-
-Before you can use Nautobot, you'll need to configure it by telling it where your database and Redis servers can be found, among other things. This is done with the `nautobot_config.py` configuration file.
-
-### Initialize your configuration
-
-Initialize a new configuration by running `nautobot-server init`. You may specify an alternate location and detailed instructions for this are covered in the documentation on [Nautobot Configuration](../configuration/index.md).
-
-However, because we've set the `NAUTOBOT_ROOT`, this command will automatically create a new `nautobot_config.py` at the default location based on this at `$NAUTOBOT_ROOT/nautobot_config.py`:
-
-```no-highlight
-nautobot-server init
-```
-
-Example output:
-
-```no-highlight
-Nautobot would like to send anonymized installation metrics to the project's maintainers.
-These metrics include the installed Nautobot version, the Python version in use, an anonymous "deployment ID", and a list of one-way-hashed names of enabled Nautobot Apps and their versions.
-Allow Nautobot to send these metrics? [y/n]: y
-Installation metrics will be sent when running 'nautobot-server post_upgrade'. Thank you!
-Configuration file created at /opt/nautobot/nautobot_config.py
-```
-
-+++ 1.6.0
-    The `nautobot-server init` command will now prompt you to set the initial value for the [`INSTALLATION_METRICS_ENABLED`](../configuration/optional-settings.md#installation_metrics_enabled) setting. See the [send_installation_metrics](../tools/nautobot-server.md#send_installation_metrics) command for more information about the feature that this setting toggles.
-
-### Required Settings
-
-Your `nautobot_config.py` provides sane defaults for all of the configuration settings. You will inevitably need to update the settings for your environment, most notably the [`DATABASES`](../configuration/required-settings.md#databases) setting. If you do not wish to modify the config, by default, many of these configuration settings can also be specified by environment variables. Please see [Required Settings](../configuration/required-settings.md) for further details.
-
-Edit `$NAUTOBOT_ROOT/nautobot_config.py`, and head over to the documentation on [Required Settings](../configuration/required-settings.md) to tweak your required settings. At a minimum, you'll need to update the following settings:
-
-* [`ALLOWED_HOSTS`](../configuration/required-settings.md#allowed_hosts): You must set this value. This can be set to `["*"]` for a quick start, but this value is not suitable for production deployment.
-* [`DATABASES`](../configuration/required-settings.md#databases): Database connection parameters. If you installed your database server on the same system as Nautobot, you'll need to update the `USER` and `PASSWORD` fields here. If you are using MySQL, you'll also need to update the `ENGINE` field, changing the default database driver suffix from `django.db.backends.postgresql` to `django.db.backends.mysql`.
-* **Redis settings**: Redis configuration requires multiple settings, if different from the defaults. If you installed Redis on the same system as Nautobot, you do not need to change these settings.
-
-!!! important
-    You absolutely must update your required settings in your `nautobot_config.py` or Nautobot will not work.
-
-!!! warning
-    If you are using MySQL as your database backend, you **must also update** the database `ENGINE` setting to `django.db.backends.mysql`.
-
-Save your changes to your `nautobot_config.py` and then proceed to the next step.
-
-#### MySQL Unicode Settings
-
-If you are using MySQL as your database backend, and you want to enable support for Unicode emojis, please make sure to add `"OPTIONS": {"charset": "utf8mb4"}` to your `DATABASES` setting. Please see the [configuration guide on MySQL Unicode settings](../configuration/required-settings.md#mysql-unicode-settings) for more information.
-
-## Optional Settings
-
-All Python packages required by Nautobot will be installed automatically when running `pip3 install nautobot`.
-
-Nautobot also supports the ability to install optional Python packages. If desired, these packages should be listed in `local_requirements.txt` within the `NAUTOBOT_ROOT` directory, such as `/opt/nautobot/local_requirements.txt`.
-
-If you decide to use any [Nautobot plugins](../../../apps/index.md), they should be listed in this file.
-
-We will cover two examples of common optional settings below.
-
-### Configuring NAPALM
-
-Nautobot provides built-in support for the [NAPALM automation](https://github.com/napalm-automation/napalm/) library, which allows Nautobot to fetch live data from devices and return it to a requester via its REST API. The [`NAPALM_USERNAME`](../configuration/optional-settings.md#napalm_username) and [`NAPALM_PASSWORD`](../configuration/optional-settings.md#napalm_password) configuration parameters define the credentials to be used when connecting to a device.
-
-To use NAPALM, add `nautobot[napalm]` to your `local_requirements.txt` so that it can be installed and kept up to date:
-
-```no-highlight
-echo "nautobot[napalm]" >> $NAUTOBOT_ROOT/local_requirements.txt
-```
-
-### Remote File Storage
-
-By default, Nautobot will use the local filesystem to store uploaded files. To use a remote filesystem, install the [`django-storages`](https://django-storages.readthedocs.io/en/stable/) library and configure your [desired storage backend](../configuration/optional-settings.md#storage_backend) in `nautobot_config.py`.
-
-To use remote file storage, add `nautobot[remote_storage]` to your `local_requirements.txt` so that it can be installed and kept up to date:
-
-```no-highlight
-echo "nautobot[remote_storage]" >> $NAUTOBOT_ROOT/local_requirements.txt
-```
-
-An example of using django-storages with AWS S3 buckets, visit the [django-storages with S3](../guides/s3-django-storage.md) user-guide.
-
-## Prepare the Database
-
-Before Nautobot can run, the database migrations must be performed to prepare the database for use. This will populate the database tables and relationships:
-
-```no-highlight
-nautobot-server migrate
-```
-
-## Create a Superuser
-
-Nautobot does not come with any predefined user accounts. You'll need to create a administrative superuser account to be able to log into Nautobot for the first time. Specifying an email address for the user is not required, but be sure to use a very strong password.
-
-```no-highlight
-nautobot-server createsuperuser
-```
-
-## Build Nautobot 2.0 UI
-
-Nautobot 2.0 introduces a new user interface. This interface is built using [React](https://react.dev/) and requires Node.js version 18 or higher to build the UI.
-
-### Build the UI
-
-Nautobot provides a management command to install the required Node.js packages and build the UI:
-
-```no-highlight
-nautobot-server build_ui --npm-install
-```
-
-This only needs to be performed manually the first time Nautobot v2 is installed. The [`post_upgrade`](../tools/nautobot-server.md#post_upgrade) command that must be ran after any Nautobot upgrade will automatically re-run this command.
-
-## Create Static Directories
-
-Nautobot relies upon many static files including:
-
-* `git` - For storing [Git repositories](../../platform-functionality/gitrepository.md)
-* `jobs` - For storing [custom Jobs](../../platform-functionality/jobs/index.md)
-* `media` - For storing [uploaded images and attachments](../configuration/optional-settings.md#media_root) (such as device type images)
-* `static` - The home for [CSS, JavaScript, and images](../configuration/optional-settings.md#static_root) used to serve the web interface
-
-Each of these have their own corresponding setting that defined in `nautobot_config.py`, but by default they will all be placed in `NAUTOBOT_ROOT` unless you tell Nautobot otherwise by customizing their unique variable.
-
-The `collectstatic` command will create these directories if they do not exist, and in the case of the `static` files directory, it will also copy the appropriate files:
-
-```no-highlight
-nautobot-server collectstatic
-```
-
-## Install Local Requirements
-
-!!! note
-    If you did not create a `local_requirements.txt` above, please skip this step.
-
-This step is entirely optional. As indicated above, we mentioned that any extra local requirements should go into `$NAUTOBOT_ROOT/local_requirements.txt`.
-
-```no-highlight
-pip3 install -r $NAUTOBOT_ROOT/local_requirements.txt
-```
-
-## Check your Configuration
-
-Nautobot leverages Django's built-in [system check framework](https://docs.djangoproject.com/en/stable/topics/checks/#writing-your-own-checks) to validate the configuration to detect common problems and to provide hints for how to fix them.
-
-Checks are ran automatically when running a development server using `nautobot-server runserver`, but not when running in production using WSGI.
-
-!!! hint
-    Get into the habit of running checks before deployments!
-
-```no-highlight
-nautobot-server check
-```
-
-## Test the Application
-
-At this point, we should be able to run Nautobot's development server for testing. We can check by starting a
-development instance:
-
-```no-highlight
-nautobot-server runserver 0.0.0.0:8080 --insecure
-```
-
-Next, connect to the name or IP of the server (as defined in `ALLOWED_HOSTS`) on port 8080; for example, <http://127.0.0.1:8080/>. You should be greeted with the Nautobot home page.
-
-!!! danger
-    **DO NOT USE THIS SERVER IN A PRODUCTION SETTING.** The development server is for development and testing purposes only. It is neither performant nor secure enough for production use.
-
-!!! warning
-    If the test service does not run, or you cannot reach the Nautobot home page, something has gone wrong. Do not proceed with the rest of this guide until the installation has been corrected. Some platforms (such as CentOS) have a firewall enabled by default. If you are unable to connect to the server url on port 8080, verify the firewall policy to allow the appropriate connections, or select an already permitted port.
-
-!!! important
-    Certain Nautobot features (Git repository synchronization, webhooks, jobs, etc.) depend on the presence of Nautobot's background Celery worker process, which is not automatically started by the `runserver` command. To start it for testing purposes, you can run `nautobot-server celery worker` separately. For production use, Nautobot and the worker processes should be managed by `systemd` rather than started manually, as described in the next section of this documentation.
-
-Note that the initial user interface will be locked down for non-authenticated users.
-
-![Nautobot UI as seen by a non-authenticated user](../../../media/installation/nautobot_ui_guest.png)
-
-Try logging in using the superuser account we just created. Once authenticated, you'll be able to access all areas of the UI:
-
-![Nautobot UI as seen by an administrator](../../../media/installation/nautobot_ui_admin.png)
-
-Type `Ctrl-C` to stop the development server. Now you're ready to proceed to [starting Nautobot as a system service](services.md).

nautobot/docs/user-guide/administration/installation/selinux-troubleshooting.md

@@ -1,194 +0,0 @@
-# SELinux Troubleshooting
-
-When installing Nautobot for the first time on a Redhat-based Linux Distribution, SELinux may prevent the Nautobot stack from working properly. An example is SELinux preventing the HTTP daemon (NGINX, et al.) from communicating to the Django application stack on the backend.
-
-## Determine if SELinux is the Culprit
-
-An example of a broken application can be seen in the Nginx error logs below:
-
-```no-highlight
-sudo tail -f /var/log/nginx/error.log
-```
-
-Example output:
-
-```no-highlight
-2021/02/26 15:16:55 [crit] 67245#0: *494 connect() to 127.0.0.1:8080 failed (13: Permission denied) while connecting to upstream, client: 47.221.167.40, server: nautobot.example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080/", host: "nautobot.example.com"
-2021/02/26 15:16:56 [crit] 67245#0: *494 connect() to 127.0.0.1:8080 failed (13: Permission denied) while connecting to upstream, client: 47.221.167.40, server: nautobot.example.com, request: "GET /favicon.ico HTTP/1.1", upstream: "http://127.0.0.1:8080/favicon.ico", host: "nautobot.example.com", referrer: "https://nautobot.example.com/"
-2021/02/26 15:16:58 [crit] 67245#0: *544 connect() to 127.0.0.1:8080 failed (13: Permission denied) while connecting to upstream, client: 47.221.167.40, server: nautobot.example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080/", host: "nautobot.example.com"
-2021/02/26 15:16:58 [crit] 67245#0: *544 connect() to 127.0.0.1:8080 failed (13: Permission denied) while connecting to upstream, client: 47.221.167.40, server: nautobot.example.com, request: "GET /favicon.ico HTTP/1.1", upstream: "http://127.0.0.1:8080/favicon.ico", host: "nautobot.example.com", referrer: "https://nautobot.example.com/"
-```
-
-A quick way to verify that SELinux is preventing the application from working is to first, verify that SELinux is indeed `enabled` and operating in `enforcing` mode, and second, temporarily put SELinux in `permissive` mode. With SELinux in `permissive` mode, the application stack can be tested again. If the application starts working as expected, then SELinux is most likely the culprit.
-
-```no-highlight
-# sestatus | egrep 'SELinux status|Current mode'
-SELinux status:                 enabled
-Current mode:                   enforcing
-```
-
-To put SELinux in `permissive` mode, execute the `setenforce` command with the `0` flag.
-
-```no-highlight
-# setenforce 0
-
-# sestatus | egrep 'SELinux status|Current mode'
-SELinux status:                 enabled
-Current mode:                   permissive
-```
-
-With SELinux in `permissive` mode, test the application stack and ensure everything is working properly. If the application is working, put SELinux back into `enforcing` mode. This is done by executing the `setenforce` command with the `1` flag.
-
-```no-highlight
-# setenforce 1
-
-# sestatus | egrep 'SELinux status|Current mode'
-SELinux status:                 enabled
-Current mode:                   enforcing
-```
-
-## Troubleshoot SELinux
-
-Troubleshooting SELinux in most instances is straightforward. Using the `sealert` command to parse `/var/log/audit/audit.log` is the fastest way to pin-point SELinux specific issues. In many cases, `sealert` will also provide guidance as to how to resolve the issue.
-
-```no-highlight
-# sealert -a /var/log/audit/audit.log
-100% done
-found 1 alerts in /var/log/audit/audit.log
---------------------------------------------------------------------------------
-
-SELinux is preventing /usr/sbin/nginx from name_connect access on the tcp_socket port 8080.
-
-*****  Plugin connect_ports (85.9 confidence) suggests   *********************
-
-If you want to allow /usr/sbin/nginx to connect to network port 8080
-Then you need to modify the port type.
-Do
-# semanage port -a -t PORT_TYPE -p tcp 8080
-    where PORT_TYPE is one of the following: dns_port_t, dnssec_port_t, kerberos_port_t, ocsp_port_t.
-
-*****  Plugin catchall_boolean (7.33 confidence) suggests   ******************
-
-If you want to allow httpd to can network connect
-Then you must tell SELinux about this by enabling the 'httpd_can_network_connect' boolean.
-
-Do
-setsebool -P httpd_can_network_connect 1
-
-*****  Plugin catchall_boolean (7.33 confidence) suggests   ******************
-
-If you want to allow nis to enabled
-Then you must tell SELinux about this by enabling the 'nis_enabled' boolean.
-
-Do
-setsebool -P nis_enabled 1
-
-*****  Plugin catchall (1.35 confidence) suggests   **************************
-
-If you believe that nginx should be allowed name_connect access on the port 8080 tcp_socket by default.
-Then you should report this as a bug.
-You can generate a local policy module to allow this access.
-Do
-allow this access for now by executing:
-# ausearch -c 'nginx' --raw | audit2allow -M my-nginx
-# semodule -X 300 -i my-nginx.pp
-
-
-Additional Information:
-Source Context                system_u:system_r:httpd_t:s0
-Target Context                system_u:object_r:unreserved_port_t:s0
-Target Objects                port 8080 [ tcp_socket ]
-Source                        nginx
-Source Path                   /usr/sbin/nginx
-Port                          8080
-Host                          <Unknown>
-Source RPM Packages           nginx-1.14.1-9.module_el8.0.0+184+e34fea82.x86_64
-Target RPM Packages
-SELinux Policy RPM            selinux-policy-targeted-3.14.3-54.el8_3.2.noarch
-Local Policy RPM              selinux-policy-targeted-3.14.3-54.el8_3.2.noarch
-Selinux Enabled               True
-Policy Type                   targeted
-Enforcing Mode                Enforcing
-Host Name                     nautobot.example.com
-Platform                      Linux nautobot.example.com
-                              4.18.0-240.1.1.el8_3.x86_64 #1 SMP Thu Nov 19
-                              17:20:08 UTC 2020 x86_64 x86_64
-Alert Count                   5
-First Seen                    2021-02-26 15:16:55 UTC
-Last Seen                     2021-02-26 15:23:12 UTC
-Local ID                      b83bb817-85f6-4f5c-b6e0-eee3acc85504
-
-Raw Audit Messages
-type=AVC msg=audit(1614352992.209:585): avc:  denied  { name_connect } for  pid=67245 comm="nginx" dest=8080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0
-
-
-type=SYSCALL msg=audit(1614352992.209:585): arch=x86_64 syscall=connect success=no exit=EACCES a0=12 a1=55d061477358 a2=10 a3=7ffc0c62296c items=0 ppid=67243 pid=67245 auid=4294967295 uid=988 gid=985 euid=988 suid=988 fsuid=988 egid=985 sgid=985 fsgid=985 tty=(none) ses=4294967295 comm=nginx exe=/usr/sbin/nginx subj=system_u:system_r:httpd_t:s0 key=(null)ARCH=x86_64 SYSCALL=connect AUID=unset UID=nginx GID=nginx EUID=nginx SUID=nginx FSUID=nginx EGID=nginx SGID=nginx FSGID=nginx
-
-Hash: nginx,httpd_t,unreserved_port_t,tcp_socket,name_connect
-```
-
-In the first few lines of the audit, `sealert` details what SELinux is blocking and provides some options to remedy the issue.
-Since Nginx is communicating with the Nautobot application via HTTP, the second option is the best option.
-
-```no-highlight
-SELinux is preventing /usr/sbin/nginx from name_connect access on the tcp_socket port 8080.
-
-*****  Plugin connect_ports (85.9 confidence) suggests   *********************
-
-If you want to allow /usr/sbin/nginx to connect to network port 8080
-Then you need to modify the port type.
-Do
-# semanage port -a -t PORT_TYPE -p tcp 8080
-    where PORT_TYPE is one of the following: dns_port_t, dnssec_port_t, kerberos_port_t, ocsp_port_t.
-
-*****  Plugin catchall_boolean (7.33 confidence) suggests   ******************
-
-If you want to allow httpd to can network connect
-Then you must tell SELinux about this by enabling the 'httpd_can_network_connect' boolean.
-
-Do
-setsebool -P httpd_can_network_connect 1
-```
-
-Executing `setsebool -P httpd_can_network_connect 1` should remedy the issue. Verify this by executing the `setsebool` command, verify that SELinux is enabled and in `enforcing` mode via the `sestatus` command, and test the application stack for functionality.
-
-The first curl command demonstrates the failure. Nginx responds with a HTTP response code of 502, indicating that it is unable to communicate with the Nautobot application. After executing the `setsebool` command, curl is used again to verify that Nginx is able to communicate with the Nautobot application. This is verified with the HTTP response code of 200.
-
-```no-highlight
-# curl -ik https://nautobot.example.com
-HTTP/1.1 502 Bad Gateway
-Server: nginx/1.14.1
-Date: Fri, 26 Feb 2021 15:41:22 GMT
-Content-Type: text/html
-Content-Length: 173
-Connection: keep-alive
-
-
-# sestatus
-SELinux status:                 enabled
-SELinuxfs mount:                /sys/fs/selinux
-SELinux root directory:         /etc/selinux
-Loaded policy name:             targeted
-Current mode:                   enforcing
-Mode from config file:          enforcing
-Policy MLS status:              enabled
-Policy deny_unknown status:     allowed
-Memory protection checking:     actual (secure)
-Max kernel policy version:      32
-
-
-# setsebool -P httpd_can_network_connect 1
-
-
-# curl -ik https://nautobot.example.com
-HTTP/1.1 200 OK
-Server: nginx/1.14.1
-Date: Fri, 26 Feb 2021 15:41:49 GMT
-Content-Type: text/html; charset=utf-8
-Content-Length: 18698
-Connection: keep-alive
-X-Content-Type-Options: nosniff
-Referrer-Policy: same-origin
-X-Frame-Options: DENY
-Vary: Cookie, Origin
-```