From 2e7258a59c3f84111e36f9515bcd58223f7410c4 Mon Sep 17 00:00:00 2001 From: Owen Date: Mon, 14 Sep 2026 09:59:03 -0400 Subject: [PATCH] Update use of - --- manage/blueprints.mdx | 4 ++-- manage/remote-node/backhaul.mdx | 2 +- manage/ssh.mdx | 26 ++++++++++++------------- self-host/advanced/database-options.mdx | 2 +- 4 files changed, 17 insertions(+), 17 deletions(-) diff --git a/manage/blueprints.mdx b/manage/blueprints.mdx index 81fd9f8..0b61592 100644 --- a/manage/blueprints.mdx +++ b/manage/blueprints.mdx @@ -402,7 +402,7 @@ private-resources: ## Resource Labels -Attach labels to public and private resources to organize and filter them in the dashboard. These are the same labels manageable from **Settings > Labels** — not to be confused with the [Docker container labels](#container-labels-format) used to define blueprints from Compose. +Attach labels to public and private resources to organize and filter them in the dashboard. These are the same labels manageable from **Settings > Labels** - not to be confused with the [Docker container labels](#container-labels-format) used to define blueprints from Compose. ```yaml public-resources: @@ -423,7 +423,7 @@ public-resources: - Label names are matched case-insensitively against existing labels in the organization. - If a label with that name doesn't already exist yet, Pangolin creates it automatically. - Each apply replaces the resource's full label list with the list in the blueprint. -- Labels are not synced for [targets-only](#targets-only-resources) public resources — omitting `labels` on a targets-only update leaves existing labels untouched. +- Labels are not synced for [targets-only](#targets-only-resources) public resources - omitting `labels` on a targets-only update leaves existing labels untouched. ## Container Labels Format diff --git a/manage/remote-node/backhaul.mdx b/manage/remote-node/backhaul.mdx index d4aa7d8..b9b5d97 100644 --- a/manage/remote-node/backhaul.mdx +++ b/manage/remote-node/backhaul.mdx @@ -199,7 +199,7 @@ This section uses AWS as an example, but the same steps apply to any VPC-style n - Add a route in the VPC's route table for the WireGuard overlay subnet assigned to your node (shown as the node's **Address** on its page in the [Pangolin dashboard](https://app.pangolin.net)), targeting the node's instance or network interface. This tells the rest of the VPC to send anything destined for the Pangolin overlay — other sites and clients — to the node. + Add a route in the VPC's route table for the WireGuard overlay subnet assigned to your node (shown as the node's **Address** on its page in the [Pangolin dashboard](https://app.pangolin.net)), targeting the node's instance or network interface. This tells the rest of the VPC to send anything destined for the Pangolin overlay - other sites and clients - to the node. AWS route table entry routing the overlay subnet to the node diff --git a/manage/ssh.mdx b/manage/ssh.mdx index 4d9cb8f..d4a2126 100644 --- a/manage/ssh.mdx +++ b/manage/ssh.mdx @@ -18,7 +18,7 @@ This page explains the configuration options shared by both resource types, give ## Default Configuration (Easiest) -When you create an SSH resource, the dashboard defaults to **Pangolin SSH** mode with **Manual Authentication**. This is the easiest path—it works out of the box with no auth daemon, no OpenSSH reconfiguration, and no extra host setup beyond running Newt as root. +When you create an SSH resource, the dashboard defaults to **Pangolin SSH** mode with **Manual Authentication**. This is the easiest path-it works out of the box with no auth daemon, no OpenSSH reconfiguration, and no extra host setup beyond running Newt as root. With these defaults: @@ -26,9 +26,9 @@ With these defaults: 2. Leave mode as **Pangolin SSH** and authentication as **Manual Authentication**. 3. Users connect and authenticate with credentials that already exist on that host. -On a [public resource](/manage/resources/public/ssh), users visit the resource FQDN, complete Pangolin authentication, then enter their host username and password (or private key) in the browser form. On a [private resource](/manage/resources/private/ssh), users connect with the Pangolin client and run `pangolin ssh username@`—Pangolin prompts for the host password. To use a private key instead, pass it with `-i`: `pangolin ssh username@ -i `. +On a [public resource](/manage/resources/public/ssh), users visit the resource FQDN, complete Pangolin authentication, then enter their host username and password (or private key) in the browser form. On a [private resource](/manage/resources/private/ssh), users connect with the Pangolin client and run `pangolin ssh username@`-Pangolin prompts for the host password. To use a private key instead, pass it with `-i`: `pangolin ssh username@ -i `. -That is the entire setup for the default preset. If you need Pangolin identities provisioned automatically on the host—without password prompts—switch to **Automated Provisioning**. With **Pangolin SSH** mode, that also works without OpenSSH or auth daemon configuration—Newt still must run as root. With **Standard SSH Server** mode, follow the host setup sections below. +That is the entire setup for the default preset. If you need Pangolin identities provisioned automatically on the host-without password prompts-switch to **Automated Provisioning**. With **Pangolin SSH** mode, that also works without OpenSSH or auth daemon configuration-Newt still must run as root. With **Standard SSH Server** mode, follow the host setup sections below. ## Configuration Options @@ -38,7 +38,7 @@ SSH resources are configured through three decisions in the dashboard. | Option | Description | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **Pangolin SSH (Recommended)** | Executes commands directly on the host via the site connector. No network SSH server is required, and you do not enter a host or port. Newt must run as the [binary](/manage/sites/install-site#binary-installation) on the host as root (`sudo newt ...`). Containerized installs are not supported—sessions may open the container shell instead of the host. | +| **Pangolin SSH (Recommended)** | Executes commands directly on the host via the site connector. No network SSH server is required, and you do not enter a host or port. Newt must run as the [binary](/manage/sites/install-site#binary-installation) on the host as root (`sudo newt ...`). Containerized installs are not supported-sessions may open the container shell instead of the host. | | **Standard SSH Server** | Routes commands over the network to an SSH server such as OpenSSH. Enter the backend host and port. To use automated provisioning (PAM) with this mode, you must configure OpenSSH to accept Pangolin certificates and connections. This mode also supports a remote auth daemon for pushing users to machines on the same network as the site connector that are not running the connector itself. | @@ -84,7 +84,7 @@ There are five valid configuration combinations. Auth daemon location is not app **When to use:** You want the simplest setup. The site connector runs on the machine you need to access, and users already have local accounts with passwords or keys on that host. -**Example:** A small team exposes a staging server that runs Newt. You create a public SSH resource with Pangolin SSH and manual authentication. Developers visit `https://staging-ssh.example.com`, pass Pangolin login, then enter their existing Linux username and password in the browser form. No OpenSSH reconfiguration or auth daemon is needed on the host—run Newt as root. +**Example:** A small team exposes a staging server that runs Newt. You create a public SSH resource with Pangolin SSH and manual authentication. Developers visit `https://staging-ssh.example.com`, pass Pangolin login, then enter their existing Linux username and password in the browser form. No OpenSSH reconfiguration or auth daemon is needed on the host-run Newt as root. **Host setup required:** Run Newt as root on the site connector host (`sudo newt ...`). @@ -94,7 +94,7 @@ There are five valid configuration combinations. Auth daemon location is not app **Settings:** Mode = Pangolin SSH · Authentication = Automated Provisioning · Auth Daemon = On Site -**When to use:** The site connector runs on the machine you want to access, and you want Pangolin identities mapped to local users automatically—no password prompts and no separate SSH server routing. +**When to use:** The site connector runs on the machine you want to access, and you want Pangolin identities mapped to local users automatically-no password prompts and no separate SSH server routing. **Example:** Your production app server runs Newt. You create a private SSH resource with an alias `prod-app.internal` and configure Pangolin SSH with automated provisioning on site. Developers connect with the Pangolin client and run `pangolin ssh prod-app.internal`. Pangolin provisions their account on the fly from their organization identity. @@ -108,9 +108,9 @@ There are five valid configuration combinations. Auth daemon location is not app **When to use:** You need to reach an existing OpenSSH server on the network and users will authenticate with credentials already configured on that server. -**Example:** A legacy database server at `10.0.5.20` runs standard OpenSSH with per-user keys. You create a public SSH resource pointing at `10.0.5.20:22` with manual authentication. DBAs visit the resource FQDN, complete Pangolin authentication, then upload their private key in the browser form to open a terminal session. If the same host is reachable from multiple site connectors, select all applicable sites—Pangolin routes through the healthiest one automatically. +**Example:** A legacy database server at `10.0.5.20` runs standard OpenSSH with per-user keys. You create a public SSH resource pointing at `10.0.5.20:22` with manual authentication. DBAs visit the resource FQDN, complete Pangolin authentication, then upload their private key in the browser form to open a terminal session. If the same host is reachable from multiple site connectors, select all applicable sites-Pangolin routes through the healthiest one automatically. -**Host setup required:** None—use your existing OpenSSH configuration. +**Host setup required:** None-use your existing OpenSSH configuration. --- @@ -132,7 +132,7 @@ There are five valid configuration combinations. Auth daemon location is not app **When to use:** The site connector runs on a bastion, and you need to SSH into multiple other servers on the same network that do not run Newt. This is the most common automated provisioning setup for multi-server environments. -**Example:** Newt runs on `bastion.corp.internal`. You have application servers `app-01` and `app-02` on the same VLAN. For `app-01`, you create a private SSH resource with destination `10.0.5.21` (the IP of the OpenSSH server on the remote host), allow TCP 22 in [port restrictions](/manage/resources/private/port-restrictions), and assign alias `app-01.corp.internal` as the domain name users connect with. Configure Standard SSH Server mode with host `10.0.5.21:22`, automated provisioning, and auth daemon on remote host (daemon port `22123`). Each app server runs `pangolin auth-daemon`. Developers run `pangolin ssh app-01.corp.internal`—the client tunnels through Newt, which proxies SSH to the OpenSSH server and coordinates with the auth daemon on that host to provision the user. +**Example:** Newt runs on `bastion.corp.internal`. You have application servers `app-01` and `app-02` on the same VLAN. For `app-01`, you create a private SSH resource with destination `10.0.5.21` (the IP of the OpenSSH server on the remote host), allow TCP 22 in [port restrictions](/manage/resources/private/port-restrictions), and assign alias `app-01.corp.internal` as the domain name users connect with. Configure Standard SSH Server mode with host `10.0.5.21:22`, automated provisioning, and auth daemon on remote host (daemon port `22123`). Each app server runs `pangolin auth-daemon`. Developers run `pangolin ssh app-01.corp.internal`-the client tunnels through Newt, which proxies SSH to the OpenSSH server and coordinates with the auth daemon on that host to provision the user. **Host setup required:** Newt on the bastion with a pre-shared key, auth daemon on each target host, OpenSSH configured on each target. See [Option 2: External auth daemon](#option-2-external-auth-daemon-ssh-on-another-server-that-doesnt-run-newt). @@ -160,7 +160,7 @@ This gives short-lived, auditable access without long-lived keys on the server. When using **Standard SSH Server** with automated provisioning, users are provisioned **just in time** on the remote system. When you connect, Pangolin ensures an account exists for you with the right permissions before the SSH session starts. Your Pangolin identity is mapped to a local username (derived from the part before `@` in your identity; if needed, a suffix is added for uniqueness). The account is created with a home directory and can be granted sudo access as configured. -With **Pangolin SSH** and automated provisioning, Pangolin handles user provisioning through the site connector directly—no OpenSSH or auth daemon setup required on the host. Newt must still run as root. +With **Pangolin SSH** and automated provisioning, Pangolin handles user provisioning through the site connector directly-no OpenSSH or auth daemon setup required on the host. Newt must still run as root. ## Host Setup @@ -175,7 +175,7 @@ Before setting up the host, create the SSH resource (public or private) in the d ## Option 1: Newt as the auth daemon (same host) -Use this for combination **4**—when the auth daemon runs on the site connector host and you are routing to OpenSSH in Standard SSH Server mode. +Use this for combination **4**-when the auth daemon runs on the site connector host and you are routing to OpenSSH in Standard SSH Server mode. ```mermaid flowchart LR @@ -214,7 +214,7 @@ Then configure the SSH server on this host as described in [Configure the SSH se ## Option 2: External auth daemon (SSH on another server that doesn't run Newt) -Use this for combination **5**—when the site connector is a bastion and each target host runs its own auth daemon. +Use this for combination **5**-when the site connector is a bastion and each target host runs its own auth daemon. ```mermaid flowchart LR @@ -246,7 +246,7 @@ flowchart LR ### Prerequisites - **Newt** running on one host (the site / bastion) with a pre-shared key for external auth daemons. -- **Pangolin CLI** installed on each server where you will run the auth daemon. See [Install Clients — Quick Install (Recommended)](/manage/clients/install-client#quick-install-recommended). +- **Pangolin CLI** installed on each server where you will run the auth daemon. See [Install Clients - Quick Install (Recommended)](/manage/clients/install-client#quick-install-recommended). ### Step 1: On the server running Newt diff --git a/self-host/advanced/database-options.mdx b/self-host/advanced/database-options.mdx index f18ebb0..ca17084 100644 --- a/self-host/advanced/database-options.mdx +++ b/self-host/advanced/database-options.mdx @@ -119,7 +119,7 @@ postgres: #### Using Environment Variables -You can instead provide replica connection strings with the `POSTGRES_REPLICA_CONNECTION_STRINGS` environment variable, as a comma-separated list. This must be used together with `POSTGRES_CONNECTION_STRING` for the primary database — the two env vars replace the entire `postgres.connection_string` / `postgres.replicas` config as a unit. +You can instead provide replica connection strings with the `POSTGRES_REPLICA_CONNECTION_STRINGS` environment variable, as a comma-separated list. This must be used together with `POSTGRES_CONNECTION_STRING` for the primary database - the two env vars replace the entire `postgres.connection_string` / `postgres.replicas` config as a unit. ```bash title=".env" POSTGRES_CONNECTION_STRING=postgresql://:@:/